<!DOCTYPE html>
<html>
  <head>
    <title>
      AOM Inclusion/Exclusion Criteria
    </title>
    <meta charset='utf-8'>
    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' async
    class='remove'>
    </script>
    <script class='remove'>
    /*Make tidy happy*/
    var respecConfig = {
          // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
          specStatus:           "unofficial",
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "aom",

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          // subtitle   :  "an excellent document",

          // if you wish the publication date to be other than the last modification, set this
          // publishDate:  "2009-08-06",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          // previousPublishDate:  "1977-03-15",
          // previousMaturity:  "WD",

          // if there a publicly available Editor's Draft, this is the link
          // edDraftURI:           "http://berjon.com/",

          // if this is a LCWD, uncomment and set the end of its review period
          // lcEnd: "2009-08-05",

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              {
                  name:       "Alice Boxhall"
              ,   url:        "http://google.com"
              ,   mailto:     "aboxhall@google.com"
              ,   company:    "Google"
              ,   companyURL: "http://google.com/"
              },
              {
                  name:       "James Craig"
              ,   url:        "http://apple.com"
              ,   mailto:     "jcraig@apple.com"
              ,   company:    "Apple"
              ,   companyURL: "http://apple.com/"
              },
              {
                  name:       "Dominic Mazzoni"
              ,   url:        "http://google.com"
              ,   mailto:     "dmazzoni@google.com"
              ,   company:    "Google"
              ,   companyURL: "http://google.com/"
              },
              {
                  name:       "Alexander Surkov"
              ,   url:        "http://mozilla.org/"
              ,   mailto:     "surkov.alexander@gmail.com"
              ,   company:    "Mozilla"
              ,   companyURL: "http://mozilla.org/"
              },
          ],
          // name of the WG
          //         wg:           "None",

          // URI of the public WG page
          //         wgURI:        "http://example.org/really-cool-wg",

          // name (without the @w3c.org) of the public mailing to which comments are due
          //          wgPublicList: "spec-writers-anonymous",

          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          //        wgPatentURI:  "",
          // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
      };
    </script>
  </head>
  <body>
    <section id="inclusion">
      <h2>Criteria for Inclusion</h2>
        <p>The first version of the Accessibility Object Model specification is not intended to be complete. It is currently impossible to make some web features accessible, so the primary goal is to resolve immediate needs quickly for existing, inaccessible web interfaces. The specification editors are purposefully deferring many useful ideas in order to maintain a realistic timeline for highest priority features.</p>
        <p>In order for features to be considered within scope for 1.0, the following criteria must be met:</p>
        <ul>
          <li>The feature addresses a critical accessibility need that is either impossible to solve, or one whose solution is so tedious to implement that even accessibility-conscious developers avoid remediation. [Note: Some non-critical features may be included if they are side effects of, or trivial to implement because of, work included to support another critical feature.]</li>
          <li>The feature addresses the accessibility of a very commonly used technique or technology. Examples of the problematic usage should exist on major web applications or many other web sites.</li>
          <li>The feature has been considered for privacy impact. [Note: It is possible the spec will mandate that privacy considerations must be addressed before partial implementations ship in browsers.]</li>
          <li>The feature is considered critical for the 1.0 release by at least two of the Accessibility Object Model [AOM] editors, representing two browser manufacturers.</li>
        </ul>
        <p>External contributors wishing to submit new features or ideas for consideration should include the following as a new
          <a href="https://github.com/a11y-api/a11y-api/issues">GitHub Issue</a>:</p>
        <ul>
          <li>Title and explanation of the problem</li>
          <li>Existing possibilities for remediation (if they exist)</li>
          <li>Demonstrable pain points caused by the lack of this feature, or by the currently available technique to address the problem this feature would solve.</li>
          <li>Optional, but desired: Complete or partial test cases, code examples, or browser user agent patches demonstrating implementability.</li>
        </ul>
      </section>
      <section id="exclusion">
        <h2>Criteria for Exclusion or Objection</h2>
        <p>Specification objections such as the following will be considered.</p>
        <ul>
          <li>Syntactical or other violations of Web API trends.</li>
          <li>Inability of a feature to be implemented in a particular browser, user agent, or assistive technology.</li>
          <li>Privacy violations or fingerprinting issues (e.g. inadvertent exposure of user details)</li>
          <li>Objections to any feature that would "Break The Web" or otherwise result in irreconcilable incompatibility with existing web APIs.</li>
        </ul>
        <p>Specification objections that disregard the following core beliefs will not be entertained.</p>
        <ul>
          <li>All native features and custom user interfaces should be possible to make accessible to all users.</li>
          <li>All web specification authors should consider and account for the accessibility of new features, ideally prior to publishing the feature.</li>
          <li>Where possible, web authors should follow best practices, use natively accessible features first, and not resort to custom user interface elements or custom input handling.</li>
          <li>Finally, because there are times when there are gaps in web platform APIs, when best practices are ignored, or inaccessible features are used, web authors should have the ability to programmatically augment and override the accessibility of existing mainstream user interfaces.</li>
        </ul>
      </section>
  </body>
</html>
